DESIGN OF HTML PAGES

TO INCREASE THEIR ACCESSIBILITY TO USERS WITH DISABILITIES

STRATEGIES FOR TODAY AND TOMORROW

VERSION 6.0

11/8/95

Gregg C. Vanderheiden Ph.D.

Trace R& D Center,  University of Wisconsin - Madison

Prepared under funding from the National Institute for Disability Related Research (NIDRR),
Office of Special Education and Rehabilitation Services (OSERS), US Dept.
of Education and in cooperation with the NCSA Mosaic Access Project.

(This is a living document.  Comments and suggestions are solicited.
GV@Trace.Wisc.Edu)

QUICK REFERENCE PAGE

DESIGN OF HTML PAGES TO INCREASE THEIR ACCESSIBILITY TO USERS WITH DISABILITIES

Gregg C Vanderheiden Ph.D.

This page provides a quick reference to the things you should consider in
designing HTML pages so that they can be used by a wider range of your
users including: people with text based browsers, people with slow (modem)
connections, people without AV capabilities on their computer, people with
helper applications missing, and people with disabilities.  Since the goal
is to make pages accessible while maintaining or increasing their
attractiveness several strategies are suggested for some areas to allow you
to select a strategy that matches your needs.

TEXT ANCHORS

It is helpful if you put enough words in your text anchors that they
would make sense if you put them at the top of the page - or - if you
jumped from anchor to anchor and had them read.  Also useful if you wanted
to jump to an anchor you knew was on the page.

GIF  and other  IN LINE GRAPHICS

1) Make sure that there is an alternate text description ( ALT-TEXT  )
of the graphic attached to the graphic for those who cannot see the
graphic.  This includes all graphics - even decorative ones. Otherwise
the user sees a note saying there is a graphic but doesn't know what it is.

2) Make your ALT-TEXT descriptions short and functional.

3) For bullets use an asterisk or a lower case o as the ALT-TEXT.

4) Include a separate Description Tag  (a capital D located next to the
picture) which takes you to a separate page with a fuller description of
graphic elements, pictures etc to allow the user without graphics viewing
ability to know what the graphic looks like.

[See also - ATERNATE TEXT PAGES  below ]

JPEG and other EXTERNAL VIEWER GRAPHICS

1) If there is a thumbnail in-line graphic of the picture Include a
separate Description Tag  (a capital D located next to the picture) (See
Above)

2) If there isn't a thumbnail of the graphic, then include a phrase like
" or a description of xxxx" which can serve as an anchor-link to a page
describing the graphic.

Note: It is possible to embedd text descriptions in some picture 
formats such as JPEG.  Someday, external viewers will be available which allow you
to view either the picture or the description from such formats - if the
text description is there.  It is a very good idea to put it there even now
- - - but it is not sufficient for access yet

AUDIO CLIPS

1) Include a phrase such as "or a transcript of xxxx"  or   "hear or
read" with the word "read" acting as an anchor-link to a page with a
transcript or description of the sound file.

Note: Someday audio file formats and players may include the ability to
handle text as part of the sound file.

MOVIES

1)  Include Caption or Text Tracks with a description of  the sounds and
words of the movie.  Quicktime for example allows text tracks which can be
viewed at the users discretion

2) Include alternate sound track which includes audio description of
videa portion of screen  mixed with the regular audio.  (If your movie
format does not support alternate audio tracks then you can provide a
second copy of the move "with audio description" included)

NOTE: A secondary video track with an interpreter doing ASL could also 
be provided with format which permit multiple video tracks.

IMAGE MAPS

1) Provide a way to access everything in the image map from text Anchors
on the page. Generally done with a list just below the Image Map.

2) Provide an alternate text only version of the page (See ATERNATE 
TEXT PAGES  below)

Note: Client side image maps are rapidly coming to the fore.  As soon as
a standard is defined and text browsers (and non-image modes of Graphic
Browsers) support them this will be another solution strategy.  Be sure to
provide the text descriptions for each URL in the Image Map.

FORMS

1) Provide alternate ways for the user whose browser or screen access
program doesn't support forms to achieve the same functions.   Providing a
form which can be downloaded and mailed or emailed in would be one
mechanism.  A phone number is another.

ALTERNATE TEXT ONLY PAGES

One general approach that can be used to address IMAGE MAP,  IN-LINE
GRAPHICS and other issues is to create a second alternate form of any
difficult pages which is laid out in straight HTML text only.  This can
provide a fast access method to your information for all users.  You may
have text only pages for just troublesome pages or all pages at you site.
Users should be able to switch back and forth.


NON-STANDARD PAGE AND DOCUMENT FORMATS

1)  Avoid non-standard HTML formats, special tags etc.  They often break
braille translation and screen access programs.   They may also cause
problems for some browsers.  If you must use them, provide an ALTERNATE
TEXT ONLY page.

2) Always provide HTML or at least ASCII forms of all documents  if they
are being provided as PDF, PS, WORD or in other forms.

TESTING

Always test your pages using a variety of text browsers and platforms
(PC, MAC, UNIX). Be sure to include text browsers and graphic browsers with
images turned off.  Can a naive user figure your pages out?  Do they have
questions about what the (unexpanded) graphics mean?

OVERVIEW

When discussing the accessibility of the World Wide Web, it is important
to break the problem down into the three basic components:

-  the source material,

-  the pipeline, and

-  the viewer.

Making the WEB accessible or usable by people with disabilities involves
all three components.   Some things need to be done when the source
material is created.  There are things that can be done at the pipeline
stage, and there are things to be done in the browsers or viewers.  This
document focuses on things that can be done when creating HTML pages
(source documents), but also mentions strategies that might be used at
other levels now or in the future to provide context and a look forward.
In some cases, problems which are dificult to address today at the source
document level may be easily addressed with changes in the pipeline or
viewers.


Making HTML (Mosaic) Documents Accessible TODAY

There are some features of the World Wide Web (WWW) which are not
currently accessible to people with some disabilities using today's
browsers (such as Mosaic, Netscape, Microsoft's Browser, AOL net browser
etc.).  In addition, many of the data formats currently do not support
accessibility annotations (captions, vocal and text annotations, etc.).  As
a result, if you want to create WWW documents that will be accessible to
people with disabilities TODAY you need to either avoid using some features
and data types or provide alternate methods for carrying out the functions
or information provided through the inaccessible functions.

In the future, alternate access methods for the standard features may be
built directly into WWW browsers, as well as the standard data storage and
transmission formats, making it unnecessary to avoid features or build
redundant mechanisms into your HTML documents.  Until these alternate
access features and standards are developed however, care must be taken in
the design of HTML pages it they are to be accessible to users with
disabilities


GENERAL COMMENTS

It is possible today to make WWW (HTML) documents that are accessible by
simply avoiding the aspects of HTML  or WWW browsers which cause the access
problems.  For example, if you create a document which ONLY has text and
hypertext links (no graphics or sounds), then you will have a document
which can be accessed by most anyone with a disability using a personal
computer that has been adapted for their use.  Although this is a rather
elementary and restricted use of Mosaic and HTML, it is nonetheless a
viable approach, as is using gopher and ftp.

However, a WWW/HTML document does not need to limit itself to text to be
accessible.  There are a number of strategies that can be used to allow use
of graphics and sound while still maintaining accessibility.


- - -  Some of these strategies require changes in either the WWW servers or
in viewers such as Mosaic.

- - -  Other strategies, however, do not require any changes and can be used
today.


Below are some of the strategies from both categories.


Organization of this document

Problems in access to HTML fall into seven basic areas:

1) In-line graphic elements, pictures, and diagrams;

2) Separate viewer based graphic elements, pictures, and diagrams;

3) Audio clips;

4) Movies;

5) Image Maps;

6) Forms

7) Specially formatted documents; and

8) Custom data structures and viewers.

Each of these is discussed in turn.  For each topic, a brief overview of
the problem is presented followed by how it should or will be possible to
handle the problem in the near future as access features are built into
Mosaic et al. (e.g., Netscape, W3, etc.).  This is then followed by things
that can be done to make HTML pages available today.

A Quick Checklist summary listing of what can be done today is provided at
the end for convenience.

1)  IN-LINE (GIF etc.) GRAPHIC ELEMENTS, PICTURES, AND DIAGRAMS

The problem:

1) People who are blind cannot view information that is presented (only)
in graphic form.

2) People (anyone) who are accessing information over a slow network
connection (e.g., modem) have only very slow access to pages with graphics
if the auto-load images features is turned on OR no access to the graphic
information if the auto-load image feature is turned off.

3)  If Web documents (or their derivatives) are to be made available via
phone or other auditory channel then some method for presenting information
that is presented in graphics would be needed.


Solution Strategies

All graphic elements would have a text description attached to them which
can be viewed instead of the graphic.

All viewers (Mosaic, NetScape, etc.) will provide the option of showing
the graphic, the text, or both.

Today there is such a feature for in-line graphics. It is an option within
the IMG definition and allows authors to attach an alternate text
description to any in-line graphic. It is commonly referred to as ALT-TEXT.

The form for this is:

The latest versions of Mosaic and Netscape support this strategy as do the text-based browsers like Lynx and DOSLynx (whose developers at the University of Kansas introduced this convention). In the future it is probable that most or all graphic browsers will also support this feature. This approach does not actually allow text descriptions to be included (and called up separately from) the picture data file, and it does not address the problem for graphics which are NOT embedded in the text (which is covered in the next section). It does however provide a mechanism for attaching text descriptions to in -line graphics (pictures that are disaplayed as part of the HTML page. The ALT-TEXT approach is very effective in most layouts - and is recommended for all in line graphics. However, on some pages with unusual layouts, it may result in pages which are confusing. In this case it is recommended that you ALSO create a separate "text only" version of the page which eliminates the use of graphics. In general, however, this makes it a bit more complicated to maintain your pages since edits must always be done to two pages when edits are needed. (If your pages are generated from a database "on the fly" this problem would not exist - but your page generation software would need to include this capability) Today, therefore, you can/should use one of these five approaches. A combination of the first 3 approaches is probably the most effective: Approach 1-1: ALT-TEXT: Provide an ALT-TEXT tag which would be displayed instead of the graphic or picture when the picture is not disaplayed (e.g. when viewing page with a text only browser, or with the "show/load pictures" feature turned off. (See above for format) [See also Picture Description Below] Approach 1-2: Alternate pages: Provide a second version of the page which does not include any in-line pictures for decoration or for anchors. Instead, text descriptions and anchors would be used. A note at the bottom of each page could allow users to move back and forth between the graphic and text-only versions of the page. (If using this approach, it is still recommended that you provide the ALT-TEXT tags described in approach 1-1 on your 'graphics version' of the page.) Approach 1-3: Embedded text descriptions: Incorporate both the graphic AND TEXT within the anchor. The ALT-TEXT text should also be included for those browsers that support it. The format would be: Recommended format today: Running text on the page running text that could serve as an anchor instead of or in addition to the in-line picture rest of running text.... An example: The newest product in our line is the Magicom portable phone, the world's smallest portable pocket phone. which yields: The newest product in our line is the[Picture of Magicom Phones] Magicom portable phone, the world's smallest portable pocket phone. OR The newest product in our line is the Magicom portable phone , the world's smallest portable pocket phone. which yields: The newest product in our line is the Magicom portable phone, [Picture of Magicom Phones] the world's smallest portable pocket phone. Approach 1-4: Database-based pages: Another higher-tech approach is to create a database-based server that creates HTML pages on demand when the user asks for them. In this manner, the pages can be constructed with or without graphics as desired by the user. An example of this is the CommerceNet server. There are now a number of software products designed to do this. This is more computationally intensive than a normal server but the pages that chage seldom could be rebuilt and stored periodically to reduce this. Approach 1-5: Filter approach (alt page) This approach is similar to Approach 4, but involves the use of a filter/translator that would exist on the server as a common gateway interface. Pages would be constructed as described in Approach 1 above and, at the direction of the user, translated into either graphic or pure text pages on the fly. This approach has disadvantages however. Since all pages must be processed on the fly (as with the databased approach), there may be a performance hit unless the filter program is used off-line to create the text versions of the pages in advance. Secondly, this approach would only work for pages on the server with the AltPage cgi. Whenever references were made to other pages on other servers, the filter would not work. Image Maps on other servers would be a particular problem unless client side image maps were used. Finally, such a filter would create text versions of pages, but since it would do it by formula, the pages may not be laid out very well or be very easy to interpret. Building access into the page or providing alternate pages which are laid out to make sense in text form (and to provide a text alternative to any Image Maps) (i.e. approach 1-2) would be much more effective. Picture Descriptions ("D" anchors) By their nature, ALT-TEXT descriptions are usually short and define the basic purpost of graphic elements. For example "Logo for XYZ company" or "Picture of ZZZ Center Building". These are instructive but do not provide very much information about the pictures. In order to allow people who are blind with additional information WGBH has instituted the practice of placing a capital "D" next to any pictures or graphics which acts as a small Anchor to a longer description of the graphic. For example, "The Logo for XYZ company consists of a globe with people of different races all standing out from the globe holding hands while a sunburst shines from behind the earth. The earth is positioned so that no particular continent is centered on the globe" Descriptions which are too long for ALT-TEXT descriptions can thus be provided... yet do not clutter up the main page. 2) SEPARATE VIEWER-BASED GRAPHIC ELEMENTS, PICTURES, AND DIAGRAMS The problem: Often in viewing HTML pages, users will encounter images or anchor phrases which will fetch and display a large graphic image. This image is often displayed using a separate viewer in a separate window on screen. If you cannot see, you have no access to this information. If you are on a slow network connection, you need to wait a long time to download the image to see whether or not you are interested in the information it contains. Solution strategies in the future Someday, all graphic data formats (such as TIFF, JPEG, PICT or their successors) will also allow incorporation of text describing the image (very useful for access and for searching or indexing pictures). External or "Helper" viewers could then allow display of the graphic, its text, or both. Servers could also be able to send the graphic portion, the text version, or both, on request from the browser. (Hot Java applets could be programmed to do this today but it is not a general capability yet.) Solutions today Until this occurs, however, the only known approach for providing alternate text for NON-EMBEDDED GRAPHICS is to provide an alternate data file with the text description of the graphic in it. (Although some graphic storage formats do allow storage of text within the data structure, the servers, browsers, and viewers do not yet allow access to it.) Approach 2-1: (generally recommended) Place an anchor to a separate page which has a text description of the picture right next to the anchor that pulls up the picture. As discussed in the last section, WGBH has instituted the practice of putting a captial "D" next to pictures or graphics in a document. If you are using a thumbnail version of the picture as an anchor to the larger picture, you could use the "D" very effectively for the anchor to the description for the picture. Approach 2-2: If the user has requested a text-only page, replace all references to pictures with references to the text files describing them. In general, Approach 2-1 is preferred, since many users may have asked for the text-only version because of speed, and may want to view occasional pictures of interest. Also, even blind users may sometimes want to pull up a picture to show someone, or to have someone describe it to them in more detail. Both of these are much easier with approach 2-1 than with 2-2. HTML Guidelines, Part 2 3) AUDIO CLIPS The problem: People who are deaf cannot access information which is presented in auditory form only. People without audio capabilities in their computer also may not have access. People who do not have the proper Audio Player Helper application may not be able to play the audio clip People in noisy environments may not be able to hear information presented auditorially. Solution strategies in the future The problems and solution strategies for audio clips are very similar to those for separate viewer-based graphic elements (Problem Area 2) and movies (Problem Area 4): They all use separate players or viewers/windows to present the content. Access in the future can be accomplished by allowing text to be stored in the data structure. Servers should be able to send the sound form, the text form, or both, on request from the browser. Players should be able to present the sound format, the text format, or both formats. RealAudio or similar formats should include the ability to simultaneously present the text version of the audio information. Solutions today The solutions strategies for accessing sound today also look essentially the same as for graphic files: Access is provided by having a separate file with a transcript of the speech or description of the sound. This separate file is accessed in one of two ways: Approach 3-1: (generally recommended) Place an anchor to a page with a text transcript or description of the sound right next to the anchor for the sound. Approach 3-2: If the user has requested a text page only, replace all URL references to sound with URL references to the text transcript or description. As before, Approach 3-1 is preferred because it provides the user with more options, allows them to use any residual hearing, and is useful to people with language impairments. It is often the case that people without disabilities are interested in the text transcripts as well. Example: Below is an example based on the White House Web server, courtesy of Paul Fontaine at the General Services Administration. Note that this example includes both ALT-TEXT access to the sound icon (audio.gif) (for users who are using text browsers or screen readers) and the text translation (al npr intro.html) of the audio file (gore.au) (for users who cannot hear or do not have audio capabilities on their computers). Suggested code: The President asked Vice President Gore to head up the National Performance Review (NPR), a project to make government work better and cost less. You can hear or read Mr. Gore's speech introducing NPR. This would look like: The President asked [Picture of Al Gore] Vice President Gore to head up the National Performance Review (NPR) a project to make government work better and cost less. You can [Sound Icon] hear or read Mr. Gore's speech introducing NPR. 4) MOVIES The only known way to make movies accessible to people with disabilities is to embed the accessibility information in the data stream so that it is time-synched with the other information. Two types of alternate format information are needed to make audio accessible: Audio: Captions or other visual representations of all important information in the sound track should be provided. (Some data structures such as QuickTime movies already have a mechanism for adding captions to the data structures.) Video: For people who are blind or who have low vision, a technique called Descriptive Video is used which provides an additional narrator describing what is happening, in between the regular dialog of the movie. Solution strategies in the future Eventually, all data structures should allow captions and audio or text descriptions of movies to be embedded in the data storage and transport formats. Servers should allow any combination of video, audio, caption, or description to be fetched on command. Viewers or players (helper applications) should allow users to specify and display any combination of the above. Solutions today Captions (for those who do not have access to sound) Approach 4-1: (Recommended) If the external viewer being used will display "closed" or embedded captions (e.g. Quicktime) , captions can be embedded in the data structure for the movie. Approach 4-2: (Good Alternate) A strategy which works for all viewers today is to have an alternate version of the movie available with open (permanent) captions which a user can choose instead of the uncaptioned version if they wish. Approach 4-3: (Good as supplement) In addition to providing captions in the movie, it is also useful to provide a separate transcript of the audio tract of the movie. It usually takes quite a while to download a movie file, and a text transcript of the audio can usually be downloaded quickly and allow one to prescreen the item before deciding whether to take the time to download it. Descriptive Video: (For those who cannot see the video portion of the movie) Approach 4-3: If the movie format allow for alternate audio tracks (e.g.Quicktime) you can provide an alternate track which includes the descriptive narration. Approach 4-4: If your movie format does not, you can provide an alternate form of the movie with the descriptive narration included in the audio track. Example - Quicktime In Quicktime you can add as many Audio or Video Tracks as you wish. The user can then select as few or many of the tracks as desired when they view the Quicktime Clip. Tracks could include - The regular Video Track - The regular Audio Track - A text Tract with captions - An Audio Tract with Video Descriptions Added - An additional Video Tract with American Sign Language Translation - Additional Text or Audio or Video Tracts to provide other languages Other Advantages In addition to the access advantages of these approaches, there are also other benefits as well. - Movies with captions can be indexed based on their captions and found using text searches of the net. - You can search for words within the captions of a movie and jump to that position in the movie. - If descriptions are provided in text mode as well, you can index and search for any VIDEO information which is contained in the descriptions. 5) IMAGE MAPS Problem: Image Map is a strategy that allows a user to click on different parts of a picture to reference different WWW pages. This type of feature, which requires an ability to see and click on particular parts of a graphic image, is completely inaccessible to people who are blind. They don't know what the picture is, and don't know where to click even if the picture is described. Image Maps are used in a wide variety of ways. Some uses are rather simple like using it to create nicer looking menu bars. Others are more sophisticated, like graphic representations of maps, diagrams, etc. Solution strategies in the future "Client Side" image map capabilities are beginning to be introduced in browsers though no standard approach has yet been agreed upon. "Client Side" image maps are similar to regular image maps except that the information regarding all of the links or "hot spots" on the image are sent to the browser along with the image map picture. If descriptions (a sort of "ALT-TEXT" for the Image Maps links) are provided with the URLs, then browsers can be designed which would give a user the choice between the graphic Image Map or a descriptive listing of the choices normally provided by the Image Map - in all text format. Solutions today Today, there are three strategies for providing access. All of them involve ways to provide an option for a text-only version of the Image Map's choices, usually as a text listing of choices. Strategy 5-1: Next to (or just below) the Image Map graphic, provide a text anchor which will take you to a new page with the text listing of the Image Map URLs on it. This is easy, but removes the listing from the context of the rest of the page. Strategy 5-2: (recommended) Have an option for a text-only page which presents an alternate form of the entire page which replaces the Image Map with a text listing of the Image-Map URLs which is optimizedto work logically within the layout of the page. Strategy 5-3: (also good if done in a way which avoids confusion) Provide the listing of Image Map choices as a text list immediately below the Image Map. This sometimes works, but can also sometimes be confusing. If used, ALT-TEXT provided with the IMAGE-MAP gif should say that the information in the IMAGE-MAP is provided in the choices below it. 6) FORMS Problem: Some HTML pages include forms constructs. At the present time it is difficult for screen readers and some browsers to handle some forms elements. Further research is being conducted in this area. Solution strategies in the future In the future, features within the browsers will allow users to display forms elements in a way that screen readers can access them. Solutions today For now the best idea would be to provide alternate mechanisms for accomplishing forms functions. 7) SPECIALLY FORMATTED DOCUMENTS Problem: As HTML evolves, new flexibility is being introduced. Tables and other constructs allow text to be laid out in side by side paragraphs and other formats which cause difficulties for screen readers For Microsoft Windows, browsers could be designed to use child windows for each place in the table, and render into the child windows. Doing this would allow screen readers interpret the page layout and develop techniques to navigate through the table heirarchy. Solution strategies for today 7-1) Keep layouts simple and straightforward 7-2) Avoid side by side presentation of text 7-3) Avoid using graphics to provide organization or structure to the document. Use HTML. 7-4) Where following guidelines 7-1 to 7-3 would interfere with the presentation of the information for some reason, an alternate page which presents the same information in an accessible format could be used. 8) CUSTOM DATA STRUCTURES AND VIEWERS Background: Some web sites are introducing special data structures and viewers to differentiate themselves or provide special functions not available with the standard tools. Access Strategies The only way for these custom data and views to be accessible is if the access is built directly into the viewer. Standard access tools do not generally work with special viewers. THANKS TO Paul Fontaine, Paul Wilson, Peter Korn and Pat Powers for their input and contribution to these guidelines. Appendix A Summary of the recent changes to Mosaic to facilitate operation by people with various disabilities (prepared by the Mosaic Access Group) 1) Implemented on the Mac and Windows platforms the display of ALT (text) tags on IMGs whenever alto-load of images is turned off. (Also benefits the "bandwidth impaired".) 2) Provided the ability to control font selection and size for all HTML text types on both the Mac and Windows platforms. 3) Provided the ability to control background color from the entire spectrum and intensity range for both the Mac and Windows platforms. 4) Provided the ability to control font colors for all HTML text types on both the Mac (whole-spectrum, all intensities) and Windows (16 color choices). 5) Provided the ability to completely change the default rendering instructions for both the Mac (by launching Mosaic via double-clicking on any of a set of Preference files you've built for yourself) and Windows (by commanding the use of a different file to fulfill the role of "Mosaic.ini") platforms. This will allow reasonable sharing of a physical machine by, say, someone with visual impairments and others without those impairments. The user with the disability will not have to item-by-item reconfigure the Browser each time it is to be used. 6) Implemented on the Windows platform the use of the left and right arrow keys as a means of navigation to the next adjacent hyperlink. Further, the user has a choice of 3 ways to indicate which anchor is "current" (i.e., will be fetched if RETURN is pressed), and one of these choices is a bordering box of any selectable color/intensity. 7) Added command icons to the Windows platform which are taken from the 'standard' Microsoft collection, hopefully facilitating interoperability with Screen Readers. 8) Added a series of audio-triggering events in Windows Mosaic. Upon one of these events occuring, Mosaic can now trigger a user-chosen, user-supplied audio file. Different audio files can be chosen for each supported event. 9) Continued to extend our bi-directional interface between Mosaic and sibling processes, to facilitate all forms of interactive augmentation, including (potentially) HTML-aware screen reader software. (We have provided the copyrighted Mosaic source code to at least 2 Universities recently who are working on such screen readers.)